perm filename ROSIE[RDG,DBL]1 blob
sn#543046 filedate 1980-11-19 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00005 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 8-Oct-80 11:35:19-PDT,763000000000001
C00005 00003 Mailed about noon, 21-October-80
C00047 00004 ∂22-Oct-80 2038 RICK at RAND-AI Re: Comments about ROSIE/Tutorial/etc.
C00051 00005 ∂22-Oct-80 2037 GORLIN at RAND-AI (Dan Gorlin) Re: Comments about ROSIE/Tutorial/etc.
C00057 ENDMK
C⊗;
8-Oct-80 11:35:19-PDT,763;000000000001
Mail-from: ARPANET site RAND-UNIX rcvd at 8-Oct-80 1135-PDT
Sender: Jeanne at Rand-Unix
Date: 8 Oct 1980 at 1134-PDT
To: CSD.GREINER at Score
From: Jeanne @ RAND-UNIX
cc: Rick at Rand-Unix, Jeanne at Rand-Unix, CSD.LENAT at Su-Score
Subject: ROSIE Tutorial
You will be most welcome at ROSIE tutorial.
Suggest you come down tonight (Wednesday) so that you can be here promptly
at 9am on Thursday for opening of session.
Take a taxi from airport when you arrive and allow plenty of time
whenever you arrive because there is danger of fog.
Call me at 393-0411, ext. 7349 or 7l53 or Rick Dow at 7681, if you need help
with reservations or anything else. Rick will be available to escort
you from the guard station.
Jeanne Cartier
8-Oct-80 15:50:56-PDT,602;000000000001
Mail-from: ARPANET site RAND-UNIX rcvd at 8-Oct-80 1550-PDT
From: Jeanne at Rand-Unix
Date: 8 Oct 1980 at 1550-PDT
To: CSD.GREINER at Su-Score
cc: Jeanne at Rand-Unix, Rick at Rand-Unix
Subject: Re: ROSIE Tutorial
In-reply-to: Your message of 8 Oct 1980 1203-PDT.
Rick has asked me to advise you that these people will be attending from
outside Rand:
Harold Cohen, consultant for Rand. He is at Holiday Inn
Bob Engelmore, DARPA Information Processing Techniques Office
Mark Stefik, XEROX PARC - We're not sure yet when he arrives.
Have a good flight!
Jeanne
Mailed about noon, 21-October-80
TO: RICK@RAND-AI, GORLIN@RAND-AI
CC: CSD.LENAT@SCORE, CSD.GENESERETH@SCORE, STEFIK@PARC
SUBJECT: Comments about ROSIE/Tutorial/etc.
! Presentation itself:
I thought the overall format was excellent -- the presentation, papers and
the like were uniformly good; and all seemed at an appropriate level and
pace. I've only a few suggested additions:
1) I never knew the precise purpose of this tutorial. Was it to sell
ROSIE or critique it; or perhaps to determine the best way of
demonstrating such systems in general, or presenting ROSIE in particular?
Many of us attendees were pondering just why we were invited, and what was
expected of us; and a concise statement of purpose would have been
valuable.
Lacking any other direction, I tried to determine how ROSIE would fit into
my (and RLL's) future plans. My comments were attempts to figure how to
get ROSIE to mesh with RLL, as opposed to simply accepting the system as
now stands. These suggestions presuppose that ROSIE is still being
designed; I now realize such heckling may have been deliterious to you, if
this conference was designed simply to sell your system.
2) Like many parts of the system itself, a statement of ROSIE's design
philosophy was never explicitly presented. I inferred the following:
"When released, ROSIE will be a static, unalterable language, whose
interpreter is based on inflexible predefined semantics. (I.e, it will be
more like a systems language, (such as ADA) than an extendable AI
tools/environment, e.g. LISP.) Its two major goals are (1)
understandability and readility, together with (2) speed and efficiency --
in case of conflict between these two attributes, it is versatility and
perspecuity which will be sacrificed. (For example, no effort is made to
facilitate further extensions to ROSIE, or to allow the user to mold ROSIE
to his specifications.) ROSIE will house those non-controversal features
which its designers deem necessary for almost any significant system.
These will be `opaguely' built into the system; and are NOT subject to
modification -- at least not by the user."
The implicit assumption is that these conventions will span the space of
anything any ROSIE user will ever wish to do; those with a slightly
different task are better off NOT using ROSIE. The user should regard
ROSIE's language as unmodifiable; he is not allowed to modify its
interpreter, and neither he nor ROSIE is permitted to reorganize (or even
reason about) the internal data structures.
3) It was never clear just what ROSIE's real mission in life was -- just
whom was it designed to serve, and for what task. As it was represented
at the ES Workshop I assumed it could be used for designing large
programs. But then it seemed strange (i.e. contrary to its philosophy;
see 2) above) that ROSIE did not have built-in parts designed to reason
about standard programming constructs, such as sequence of operations.
[ROSIE doesn't "know" about sequences the way it knows about classes --
i.e. it includes determiners, which are only applicable to classes; but
not a pre-defined semantic interpretation for things like BEFORE and
AFTER?]
Was ROSIE designed to handle general applications? If so, how can the
claim that "then ROSIE probably isn't what you should be using" serve as
an acceptable justification, to explain away some limitation?
I would be nice to see explicitly what assumptions and conscious decisions
went into ROSIE's design. For example, how large do you image the
eventual user's Knowledge Bases will be? Will it only be used
interactively? ...
4) The final suggestion is to include a projected life story for ROSIE:
Do you imagine ROSIE will undergo a KRL-like sequence of generations?
Will the user be allowed to modify its internals, ever? Is RAND committed
to support ROSIE indefinitely? etc.
! General comments
I was quite (positively) impressed with what ROSIE could do -- it could
certainly handle 95% of all the tasks I could ever imagine, and do so in a
fairly clean and elegant manner. What has me frustrated is not the
particulars of those remaining 5% of the facts -- after all, no one
expects any system to please all the users all the time. Rather, my
concern was due to the fact that so many arbitrary decisions were built
into ROSIE, and encoded in such a way (and in such a philosophy) that
every user will be forced to mold his data to fit these conventions.
The approach sounds similar to Yale's: All we need to do is build in the
5 basic this-es and 6 primitive that-s. As no one will ever need anything
else, the system will never need to change. So why bother installing the
tools which faciliates (or even simply allow) the system to be modified?
Representation languages are based on the premise that this user should
decide what consistutes a natural decomposition of the problem. They are
necessary because such systems soon become so big and intricate the user
is unable to cope with its complexities effectively. Such languages can
be viewed as general tools, designed to assist the user in building and
later modifying a large system.
From this perspective it is hard to understand the assumption that the
user will happily accept someone else's conception of how he should
process his data, or how he should go about drawing inferences. Given
that ROSIE was designed to accept as input arbitrary "domain" facts --
about people, hats, or frogs; together with their properties -- why has so
little been done to permit the user to specify how to deal with these
facts -- how to perform inferences, retrieve stored values or propage
effects. How can ROSIE simultaneously assume that (1) there is much
declarative information which is particular to this problem, which should,
as such, be input by the user, and (2) there is nothing the user needs to
say about how to process this information -- i.e. a single general
processor is sufficient to deal with this, as well as ANY OTHER PROBLEM;
and so there is no need for the user to enter this type of information.
ROSIE is, of course, not alone in making this artificial distinction --
there has been a historical dichotomy between enterable data and static
program. That doesn't mean this approach is any more justified, or less
limited.
This problem can be readily solved by a single obvious-in-retrospect
"trick": Simply leave all of the control mechanisms visible and
modifiable. This would be achieved elegantly if all of the internal parts
were encoded in forms ROSIE itself can understand (e.g. as ROSIE stylized
English). It is, however, quite sufficient to leave these as LISP code;
the only necessary requirement is that they be reachable.
Ideally ROSIE's guts should be self-descriptive and modifiable. Given
that ROSIE was designed to help construct other programs, it seems strange
to find it unable to turn inward and aid in its own modifications. After
all, this particular system is just the sort of complex beast ROSIE was
designed to construct and manipulate. It's as if these builders do not
believe in the very raison d'etre for their own system. ([RLL-1: A
Rep...] illustrates why, with proper bootstrapping, this need NOT lead to
an infinite descent.)
The argument that such flexibility causes inefficiency is simply
fallacious. Yes, it will cost considerable additional space, but already
much of ROSIE's design seems strongly based on the assumption that vast
quantities of storage are just around the corner -- to house both the
system itself and the user's data. Employing Cognitive Economy ideas
(e.g. retaining multiple version of various parts of the program) we've
seen such language can reclaim otherwise lost execution speed; so speed
need not be sacraficed either.
The next standard concern is that this way the user has too much power,
and can all too easily screw himself. There are two arguments against
this: (1) We recommend that ROSIE provide nice safe tools -- which know
about what the user should and should not be tampering with. Of course,
the sophisticated (and maschocistic) fellow can still ignore these access
mechanisms, but (2) there is no way we can really provide a totally idiot
proof system. No matter how many precautions we include, the user can
always type ↑C, or do funny things with random parts of memory. The only
guarantee we'll make is that the user will be safe if he plays only with
the toys we provide. [Note these enclosed tools are part of the ROSIE
system, and should, as such, also be alterable.]
Enough philosophy. Many of these points, at some level or other, can be
found in "A Representation Language Language" [AAAI#1 165-9],
"Meta-Description and Modifiability" [Genesereth&Lenat, HPP 80-18] "RLL-1:
A Representation Language Language" [HPP-80-9], "MRS Manual" [Mike
Genesereth & Dave Smith, HPP-80-24], description of Cordell Green's Chi
project (especially Jorge Phillip's PhD thesis) and (sorta) in Jon Doyle's
PhD thesis (c.f. p. 35 on).
! Specific limitations
This list which follows should NOT be interpreted as a want-list;
I do NOT want one of
ROSIE's builders to sit down and integrate solutions to these particular
problems into ROSIE's code. Nor am I particularly interested in finding
some thirty line ROSIE progam which sorta simulates some fact which I can
state in one sentence; and would be even more disappointed to find I would
have to keep asserting additional facts, one for each new proposition
enterred, for my requested rule to continue to hold. (Of course,
finding that such a
possibility does exist would constitute a step in the right
direction.) Both of these approaches represent what I feel to be a major
loss in perspecuity -- which I thought to be one of ROSIE's main selling
points.
Unfortunately these examples reflect my rather incomplete
understanding of the ROSIE system, which does not necessarily do
justice to the actual ROSIE system.
I would be pleased to discover that ROSIE could indeed perform some task I
here claim was beyond its capabilites.
Please realize the purpose of this list is
not to badmouth ROSIE, per se; rather it was designed
to demonstrate the
limitations which arise whenever the user is supplied with
a single unalterable interpreter.
The categories used below are merely first stabs at an ordering of the
ROSIE's limitations. Many of these examples overlap into other divisions as well.
!O. Lack of intensional objects.
This has already been acknowledged as a shortcoming;
I am including it in my list only for completion.
This omission leads to other problems - such as the inability to
deal with skolemized variables (eg Mark's
Any man with a hat ...
where the particular hat is a function of the particular man.)
I. The Backward Deduction Inferencing Capability is fixed, and unalterable.
All it can do, apparently, is specify
For-All x in C. Q(x) & M P(x) => P(x)
where "M P(x)" is a modal statement that asserts P(x) is not inconsistent.
Limitations:
1) Can one refer to existential quantification?
[Note this could be handled using intensional objects; but lacking those,
this omission is even more glaring.]
How can I assert that
"There is a green frog."
in such a way that asking
"Are all frogs red?"
is guaranteed to be False.
Note ROSIE's current trick, of simply skolemizing this frog into a constant,
is NOT sufficient.
[Scenario:
Assert any thing red is not green.
Assert there is a green frog.
?
Frog#32
Frog#32 is a FROG.
Frog#32 is green.
Assert Frog#32 is red.
Display Are all frogs red?
True.
]
2) Why must each description have a scoping class?
This forces the user to talk about "things", to sidestep this limitation.
However, this happens in English as well, so this point is not major.
3) Modalities
How can I state that
"Any proposition not provably true is false."
Reason Maintenance
"The proposition X is only true when proposition Y is true."
"The proposition X depends on Modus Ponens."
Resource limitations:
"Spend up to 10 cpu second trying to deduce proposition X."
"Do not spend over 10 cpu second trying to deduce any proposition."
This is crucial for work with beliefs and alternate worlds, where I might
want to assert something about John's deductive mechanism (i.e. that he
does NOT know Modus Tollens).
4) Disjunctions:
From
Assert Tom is either green or blue.
Assert Tom is not blue.
could ROSIE infer that
Tom is green.
?
Similarly could ROSIE do the right thing with
Assert any man is either green or blue.
?
5) Arbitrary complexities:
E.g. It should be easy to "enhance" the inference engine to work slightly
differently.
In one statement I should be able to say
Combining "Any <descr1> is a <descr2> with (any probability (p))."
with "Any <descr2> is a <descr3> with (any probability (q))."
yields "Any <descr1> is a <descr3> with r." where r = p*q.
Perhaps an even more general statement, describing how to combine probabilities,
should be expressible.
II. Why is the interpretation of each phrase so rigidly predefined?
This seems quite a loss, especially considering its arbitrariness.
For example, why do you insist that every fake diamond be an diamond?
This would be acceptable if there was an easy way to override it -- for example,
a statement that
"Any thing which is a fake -class- is not a -class-."
where -class- varies over every class. (See III.1). )
Analogous, it is a shame the user cannot state that
"Any thing which is a -class- in -anything- is a -class-.",
etc.
[This would be used to deduce that
TheAmazon is a river.
given the assertion that
Assert TheAmazon is a river in Africa.
]
ROSIE "knows" a lot about classes, and handles them fairly nicely. This
is NOT true of sequences, which can, at best, be expressed only as lists.
Why not give some semantics to "BEFORE", or "CONCURRENTLY", by analogy to
THE or A.
Providing the user with this ability to change the ROSIE system would be a
giant step forward, even if the user had to issue these redefining
instructions in LISP. It would be much better yet if the user could
simply issue such ROSIE-altering commands to ROSIE in the ROSIE language.
III. Many facts only stored implicitly.
For example, it is difficult to refer to individual classes, relations,
prepositions or propositions; and harder to quantify over any of these
sets.
1) Classes
[Note many of the problems mentioned throughout would be solved if we
could place an arbitrary class in a user function or procedure.]
Is there any way to refer to a particular class, as an entity with properties?
For example, can I say
Assert the number of frog is 5.
and
Assert the latest-addition to frog is Frogette.
where this "frog" is the same object I use when I state that
Assert Frogette is a frog.
If so, can I set the demon
"When any '-Y- is a -X-' is asserted,
LET the size of -X- be 1 + the size of -X-."
It appears this would really require an infinite number of
assertion to put into effect (ie one for each possible class -Y-).
[This might get even more complicated if -X- could vary over every
description -- this would require that ROSIE have to have a unit
which represents, for example, the set of "lakes in Africa".]
2) Prepositions
How could the user define new ones, or assert some property of an existing one --
eg that the "value" of "with" must be a probability,
or which lists those functions which use "of" in their invocation pattern.
3) Propositions
Quantification:
Describe all unary propositions involving Fred.
Describe all positive propositions involving Fred.
[similarly CURRENT tense, or PAST TENSE;
or relations which start with Is-A, ...]
Inheritance:
Any man should `inherit' all the relations stored on TypicalMan.
[That is, after asserting that John is a man,
John should inherit a copy of each proposition stored on
TypicalMan, mutatis mutandis.]
[It would be even better if the user had first indicated which
properties/relations were inheritable, and which pertained to this entity
alone. Then John would receive only the semantic attributes of TypicalMan,
not the syntactic properties of this unit.]
Epistemological Marks:
There are many facts - such as marks which indicate epistemological status
- which should be associated with the actual proposition. Eg The fact
that "Every purple mushroom is purple." is definitional, whereas the
statement that "Each purple mushroom is poisonous." is simply an
assertion, which just happens to be true.
Much of what "ANY" does would be clarified with such marks as well:
Given
Assert Fred is an albino frog.
Assert Any frog's color is green.
Assert The color of any thing which is albino is white.
The result of
DISPLAY The color of Fred.
is ill-defined. - i.e. it might be either "Green" or "White".
It would be nice to be able to state
Assert the proposition that
'Any frog's color is green'
is assertional to frog.
Assert the proposition that
'the color of any thing which is albino is white'
is definitional to albino.
Assert ... ANY should look first at Definitional properties before
Assertional ones ...
[Note the final assertion requires a handle into the inference procedure
associated with ANY -- see I. above]
In this case, the answer would clearly by "White", as desired.
If and when intentional objects are implemented,
they could make heavy use of such marks.
They should be used to differentiate between
The green man hit the baseball,
which is defined as a man who is green, and happened to hit the baseball, from
The man who hit the baseball is green,
which is defined as a man who hit the baseball and happens to be green.
This distinction is essential for matching purposes.
4) Relations
Describe all proposition containing the Is-A relation, which involve Fred.
[This would list every class to which Fred belonged, eg:]
Fred is a boy.
Fred is a man at [age] 12.
Fred is a sailor on HMS-Pinafore.
How about a user defined relation:
The "is-tall" relation is nice.
The "Isa-Of-With" relation is significant.
Any significant relation is nice.
then
Describe all proposition based on a nice relation, which involve Fred.
[It would be even nicer if the user could instruct the parser to accept phrases
like
Describe all nice relations in which Fred participates.
which would mean the same as the above statement.]
On a similar vein, if one could readily quantify over relations, the basic frame
statement would be a cinch:
Assert for every asserted proposition which involved a WAS relation,
the corresponding proposition, with the WAS replaced with an Is,
is provably true.
[Side question: Is the "asserted proposition" construct permissible,
meaning, of couse, "a proposition which was asserted"?]
Can I relate each n-ary relation with a corresponding n+1-ary relation,
whose final arg relates to time -- ie first consider
Assert for every instantiation of Isa, (Isa x class),
the proposition (Isa' x class t0) is provably true.
then extend this by quantifying over all relations.
Similarly one might want to conjoin an epistemological mark on each proposition,
using this type of trick.
There are many properties associated with properties as well.
For example
Assert income is singlevalued.
would cause an error if
Assert the income of Fred is 45.
followed
Assert the income of Fred is 100.
[Another possibility: this might have the effect of simply erasing the
earlier (Income John 45) proposition.
The choice of which of these to use should depend, of course, on the
current user's whims.]
Note this is not always the case - eg we can have
Assert the son of Fred is John.
Assert the son of Fred is Mark.
(In fact, it should be an error using "the" above - as the property was not
singlevalued.)
[Another improvement to the parser:
How about giving "sonS" the obvious interpretation?
So
Assert the sons of Fred are John and Mark.
would accomplish the same as the above two sentences.]
Finally, can ROSIE reason (or assert facts) about Demons, or Any
statements, qua facts? For example, how can one phrase the instruction to
delete a When demon after its one execution, or to eliminate any Any demon
which has not fired today, or ...
IV. The parser is, to the user, totally inflexible.
This linguistic issue is not a major shortcoming. Still,
1) it would be nice if ROSIE could adapt to the user. For example, some
user could instruct ROSIE that he (intentially or otherwise) constantly
mispelled some keyword, or misordered some phrase -- this would allow a
preparser to replace this "error" with what the user really meant.
2) How about allowing the user to define a SUBSET of the grammar.
(Clearly this will not be ambiguous if the full grammar is not.) For
example, for type checking reasons, the user may want to insist that the
"value" associated with the preposition "with" be a probability. That way
"roof with 0.7" would be acceptable, whereas "roof with spikes" would blow
up immediately. (Of course, better yet would be allowing the user to
define a new "with-probability" preposition, with this typing.)
3) The invocation pattern of a function is fairly constrained. Enlargening
this, to include, for example, adjectives before the noun, might prove a big
win.
V. Grab bag
1) Can the user create his own monitor, or submonitor? Ideally, he should
be able to construct his by slightly modifying an existing one. For
example, could the user define a monitor which chooses a rule at random
and executes it. Unless that rule RETURNed or QUIT, this monitor would
then execute another rule, and so on. Are there sub monitors? (Ie a
partition of the ruleset into sub groups of rules, where each such subset
has its own monitor.)
2) I got the impression that only primitive sentence could be propositions.
If true, that's a considerable limitation.
3) Is it possible to reason about some user or system function -- that is,
store axioms which it satisfies, and use these facts. Better, could one
make some change to these assertions, and see the function itself altered
correspondingly. (Similarly for Predicates and Procedures.)
4) Cognitive Economy - can the same name be used for a ROSIE relation as
for a user function. Then when the (Father of X) inquire was made, the
Father function could first see if the triple (Father X Y) appears in the
KB; and if not does some other calculations. The result of this execution
may then be cached away (so subsequent calls would be faster.)
5) Does ROSIE have different input modes
-- for example, a useful one would be a paraphrasing mode,
in which ROSIE returns what it thought the user had said.
6) Can the user input, and ROSIE use, MetaRules? This would be a nice way
for the user to help ROSIE perform a derivation. For example, can the
user order the rules ROSIE uses, or tell ROSIE how to quickly prune away
irrelevant ones? (This had been a problem with PROLOG, and before that
with PLANNER. An article in IJCAI#6 presents arguments for the utility of
this idea.)
! Path towards a solution:
There are many ways to solve these particular shortcomings. One is to
make them features: "ROSIE intentionally handles a fixed predefined and
stylized subset of English, to avoid ambiguities, and for parsing speed."
Another is to address the precise complaint, and add in code designed
explicitly to fix this "bug". These are NOT the approaches I would
advocate. After all, these particular issues only reflect my biases,
which should have no more weight than any one else's -- in fact, less, as
I'll not be using ROSIE in the immediate future. This collection of
troublesome facts was intended to demonstrate the major problem inherent
to any closed system: that any outsider can easily produce a host of
problems, which either cannot be handled, or which cannot be handled
easily.
This problem goes away if the guts of your system is left exposed to the
user; and if he is provided with a library of effective tools for altering
the parts of this interpreter in whatever manner he wishes. The designer
is still expected to build into ROSIE the things which seem expedient for
95% of the cases, but now the user is NOT forced to use these when these
conventions prove inadequate or inappropriate.
This way there is no need to either apologize for ROSIE's ineptitudes, or
hastily get a system programmer to patch up a solution -- after all, the
user now has last word in what ROSIE can and will do, and with it the
responsibilities for any shortcomings in his design. At this point he
becomes responsible not only for modifying his system, but for maintaining
it as well. Note these tools are not that expensive to construct; they
may be essentially the same ones you, the system builder, use for your
manipulations. The time required now to build these tools for user use
will be repaid many times over by the time you'll save by NOT having to
modify ROSIE, as the user himself can have his whim. The other cost - of
making the system itself understandable - hardly seems a goal to avoid.
Among other desirable effects, this makes much of the system far easier to
actually build.
Based on my experience working with RLL-1, I strongly believe I actually
spent LESS time and effort building a self-modifiable system than I'd have
spent constructing a more opague system. That is, it was easy to upgrade
RLL-1 using these modifying tools -- it was, in fact, trivial to perform
simple alterations. There were big gains from a more esoteric point of
view as well -- I was amazed at how many issues became now non-issues when
the interpreter itself was explicit. (Eg just what does the "Any" demon
REALLY mean?)
∂22-Oct-80 2038 RICK at RAND-AI Re: Comments about ROSIE/Tutorial/etc.
Date: 22 Oct 1980 1818-PDT
From: RICK at RAND-AI
Subject: Re: Comments about ROSIE/Tutorial/etc.
To: RDG at SU-AI, gorlin at RAND-AI
cc: csd.lenat at SU-SCORE, csd.genesereth at SU-SCORE, stefik at PARC-MAXC
In-Reply-To: Your message of 21-Oct-80 1256-PDT
Russ:
I am grateful for the careful and persuasive remarks you
prepared on ROSIE. More than any thing, they heighten and articulate
the tensions associated with a project like ROSIE: exactly what is
the purpose and who is the user community. Inviting you has been
repaid. The answer to most of your questions is that they provide
capabilities not required by the intended audience for ROSIE, who are
pretty much unskilled-in-AI knowledge programmers. I don't think
that ROSIE Makes all of their task easier than it would be if we
had all the capabilities you suggest. For example, I personally
prefer many of the more powerful capabilities you recommend since
they make lots of things easier. On the other hand, it's not
immediately obvious how to gracefully extend the system. It's a
large (ADA=like) programming system, and unfortunately many features
interact with others. That's not copping out, that's admitting that
you've given us several more things to chew on. As that process
unfolds, I'll consult with you to see if we can't get some of these
capabilities realized. I warn you, however, there are more
constraints than immediately obvious. For example, all propositions
are primitive sentences because that's what's in the data base and
that makes matching well-defined, simple, fast and compilable.
We don't carry around arbitary variabilized expressions for later
evaluation. Why not? Because we want something that can compile, be
simple, and be fast. Maybe we're sacrificing too much for something
of too little value, but those are the really interesting and hard
issues.
I have read your note once carefully, and it's apparent to
me that your ideas are worth more than that. I will return!
Again, thanks,
Rick
p.s. our intention was to inform potential users and instigate
useful reactions. i think we got that from you.
-------
∂22-Oct-80 2037 GORLIN at RAND-AI (Dan Gorlin) Re: Comments about ROSIE/Tutorial/etc.
To: RDG at SU-AI, rick at RAND-AI
cc: csd.lenat at SU-SCORE, csd.genesereth at SU-SCORE, stefik at PARC-MAXC,
cc: GORLIN at RAND-AI
In-Reply-To: Your message of 21-Oct-80 1256-PDT
Russ,
Ditto on rick's comments. Your critique is by far the most comprehensive
and cogent we've received, and will undoubtedly affect Rosie's future
in a big way. Much more to say, but I'd rather do it over the phone
after having contemplated the issues. Thanks for the help.
danny
-------